Increasingly, computer based tools are being relied upon to assist businesses in solving a wide range of problems. Computers are especially useful for organizing and managing large quantities of information. There is a particular need to manage and streamline the flow of information in complex projects. However, significant flaws exist in the architecture of currently known project management applications. Within any team of organizations working on a project, one organization (usually the organization that licenses a project management software product) owns and manages all of the information on the project. Therefore, this organization receives a high benefit while all other organizations receive only moderate benefits. By extension, the project does not fully realize the potential of the technology.
Any project that involves the collaboration of multiple organizations requires continuous communication between these organizations in the form of creating, copying and transporting information.
A project typically begins when each organization involved in the project creates a body of information and breaks that information into at least three subsets. The largest subset is copied and transported to all of the other organizations. Of the two subsets left, one is copied and transported to some, but not all, of the other organizations. The remaining subset is not copied or transported, but stored and used only within the organization that created it.
As the project proceeds, each organization continues to create new information on a daily basis, which is again broken into subsets, and the copy—transport—store—process is repeated. Through this, a team mechanism evolves in which each player holds an island of copied instructions that is essential in order to perform its work. Furthermore, the copy—transport—store—process does not stop between organizations, but occurs within organizations as well. Each organization has a number of its own islands in the form of headquarters, departments, branch offices, field offices, traveling personnel and the like.
If one organization's (or part of an organization's) set of instructions is not up to date, it will not be able to perform its work or, worse, will perform it incorrectly. An important factor in the efficiency of a team, then, becomes the rate and accuracy at which the instructions are copied and synchronized. Because of this, the copy and synchronization process consumes a great deal of time and resources within each organization and, thus, the project.
There was a need to create a method for utilizing a central store in which the information and communications from each organization was created and shared with all, some, or none of the other organizations. This approach eliminated the copy and transport chores. There was no longer a “rate” at which the information was transported because it was created in-place and was available to anyone as soon as it was created. The idea of the “accuracy” of the copy was no longer relevant because each organization was using the original, not a copy.
However, this central store method has been discussed more times than implemented. Unless a project was very large and lasted for several years, the cost to assemble and maintain such a dedicated network between all organizations could not be justified.
Recently, the Internet or World Wide Web has emerged as a ubiquitous, low-cost public infrastructure. Not only is the Internet capable of acting like a dedicated project network, it is also well suited for carrying an application like the central store model above.
The construction industry is an example of where web-based project management services are starting to change how business is done. The following detailed description of both past project management services and the system of the present invention are described herein for a construction industry organization for the sake of example. The system of the present invention is useful in a variety of industries and such construction industry example should be viewed in an illustrative and not limiting manner. The system of the present invention has broad applications and uses in many industries and such uses are within the contemplated scope of the present invention.
From its beginning, the management of construction projects on the Internet has centered on the concept of Project Specific websites; that is, a website specifically created for one project. Using the prior art Project Specific Model, as shown in FIG. 1, the organization that hosted a project created an organizational account, 10, just for that project. Thus, if multiple projects were to be hosted within the Internet application by one organization, a new organizational account had to be created for each project.
The Project Specific Model created inefficiencies in the form of redundancy and lack of shared resources. Master lists of data 11 and 12 such as companies, cost codes and usernames had to be copied and recreated for each new project. For example, in FIG. 1, User 1 had three usernames and passwords 20 one for each project. Using a security model like this, to effectively distribute all of the information for all of it's projects to all of it's employees, a company with 60 employees and 30 projects per year would have to create and maintain 1800 usernames and passwords per year.
Additionally, because each project logically resided in separate organizational accounts 10, there was no functionality for data to be aggregated across projects; for instance, reporting on total man-hours on all projects or total costs for projects 1 and 2 is not possible. Since a user had to log-out and log back in to each project separately, the Project Specific Model also had an awkward process for switching from one project to the next while using the application. Furthermore, in some applications built on the Project Specific Model, each project had to be accessed by entirely different URLs, or addresses on the Web.
Because of these inefficiencies in usability, the Project Specific Model could not be deployed in an enterprise-wide approach. That is, within or across organizations, all projects could not be managed effectively using an Internet application with this model. Instead, some projects would be on the Web and the rest of the projects would be tracked in other applications on the organizations' local area networks (LANs) or by conventional hard copy methods. Thus, the benefit of online collaboration between organizations and remote access to data was offset by the cost of disintegrating enterprise-wide information and format.
An alternative to the Project Specific Model was the prior art Enterprise Model. An Enterprise Model application, as shown in FIG. 2A, allowed one organizational account 30 to hold multiple projects. Because of this, one set of master lists 31 could be shared between all of the projects within an organizational account.
Because each organizational account enforced security between all of the users and projects within it, a user needed only one username and password for each organization as opposed to each project. Thus, in FIG. 2A, User 1 had only two usernames and passwords 40 one for each organization that held a project in which User 1 was involved.
Various currently used Enterprise Model approaches are the web-based project management applications built by Cephren, Bidcom, Buzzsaw and Constructware. These Enterprise Model applications are not only designed for, but provide the most benefit to, those organizations that track every project from it. In the Enterprise Model, the host organization has a single source of project information enterprise-wide, providing efficiencies in the form of common access and format across projects as well as the ability to aggregate data between projects (for example, total dollar volume of retail vs. healthcare or, workload statistics across all project managers). Furthermore, in the Enterprise Model, all projects are presented at one Web address and each user has one username and password for each organization. The applications' security features then discern what parts of what projects to make available to a given user.
While the Enterprise Model provides greater efficiency for those organizations hosting project information, other team members, or those organizations working on the project but not hosting project information in the system, are left with many of the same integration problems that hosting organizations faced with the Project Specific Model. That is, data and work processes on other projects in the enterprise reside on another system. For example, in FIG. 2A, assume that User 1 is from a third company, not pictured, called Organization C which is involved in three other projects, not pictured, Project 4, Project 5 and Project 6. Because Projects 4, 5 and 6 do not involve Organization A or B, Organization C must manage these projects in another system. Even if Organization C had its own account in the Web application to house and manage Projects 4, 5 and 6, the information in the projects would not be integrated with that of Projects 1, 2 and 3 because they would be in organizational accounts other than its own.
This illustrates the major drawback of Enterprise Model systems: just as the Project Specific Model does not allow aggregation and integration between projects, the Enterprise Model does not allow aggregation and integration between organizations. Because of this, one organization must act as a public clearinghouse for all data and work processes on a particular project. FIG. 2B shows an example of this prior art system in which all lines of communication between five organizations run to and from one organization, the host. In the offline world, however, multiple organizations share information with each other in a complex network of privileges and permissions defined, in part, by each organization involved, not by one omnipotent organization. FIG. 2C illustrates this, where lines of communication exist between each organization allowing the information to be shared between any two organizations on their own terms. For example, given all of the data created by Organization C, a portion will be made available to all of the other organizations while another portion will be made available to only Organization D. Yet another portion may only be made available to Organization E. The remaining portion is not shared with any other organizations, but distributed within Organization C for internal use only.
In the Enterprise Model, this level of control over the distribution of information between multiple organizations is only possible for that information that is shared between the hosting organization and other organizations, not between multiple “other members”. Technically, the hosting organization could employ the security features of its site to create these complex gateways between “Other Members”, but it would be awkward at best and incomplete at worst. For example, in FIG. 2B, if Organization C wanted to share information with Organization D, but not with Organization A (the Host), Organization C would have to trust Organization A to essentially not look at the information. Even here, while the honest hosting organization would not make itself privy to the content of the information, it still knows the type of information being shared and that the information is not being shared with it.
Both the Project Specific and Enterprise models are carryovers of application structures that operated on Local Area Networks (LANs). Prior to the wide use of the Internet, each organization had only its own LAN that was a network in and of itself, not connected to any other organizations' LAN. Since there was no physical connection tying these networks or their applications together, extending the application models to allow integration between organizations returned no value. However, as the Internet emerged to connect the information infrastructures between organizations, the current offering of Web based applications appeared and were created utilizing the LAN-based Project Specific and Enterprise Model approaches.
In this sense, these applications were simply ported, as is, from LANs to the Internet. As a result, the communication model that emerges when a group of organizations uses these applications on a number of projects is paradoxical in that numerous, disconnected, virtual LANs are formed on top of a large shared network. This happens because the Project Specific and Enterprise models do not take advantage of the unique opportunities provided by a large network shared by multiple organizations.
In view of the various shortcomings of the existing project management models, there is a substantial need for an improved computer based application that provides a complex fabric of data, communication, and workflow exchange to all members of a project based supply chain.